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Standards  and  Technology,  nor  does  it  imply  that  the  materials  or 
equipment  identified  are  necessarily  the  best  available  for  the 
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1.  The  Testing  & Registration  (T&R)  Service 

The  Testing  & Registration  (T&R)  service  is  an  online  database 
service  developed  by  NIST  and  owned  by  OSINET  Corporation.  It 
provides  an  up-to-date  reference  for  announced  Open  System 
Interconnection  (OSI)  products  in  order  to  help  users  select 
interoperable  implementations.  Products  that  have  been  successfully 
tested  for  interoperability  using  approved  OSINET  tests  and  test 
procedures  are  listed.  These  products  are  protocol  suites  headed 
by  layer  7 protocols.  Currently,  Message  Handling  System  (MHS)  and 
File  Transfer,  Access,  and  Management  (FTAM)  protocol  suites  may 
be  registered. 


2 . The  T&R  Service  Environment  and  Equipment 

The  T&R  service  is  implemented  on  a Digital  Equipment  Corporation 
(DEC)  MicroVAX  II  operating  under  version  5.1  of  the  VAX/VMS 
operating  system.  This  computer  is  an  end  system  containing  the 
MHS  application  with  the  supporting  lower  layer  software. 


2.1  The  T&R  Service  Network  Topology 

OSINET  X.25  networking  services  are  provided  by  AT&T  and  U.S. 
Sprint.  End  systems  on  the  AT&T  network  can  interoperate  with  end 
systems  on  the  U.S.  Sprint  network.  End  systems  can  be  directly 
attached  to  one  of  these  two  networks  or  they  can  be  attached  to 
a local  area  network  which  connects  to  the  X.25  network  through  an 
intermediate  system. 

The  Corporation  for  Open  Systems  (COS)  is  the  new  secretariat  for 
the  OSINET  Corporation.  During  the  period  of  August  - September 
1991,  the  T&R  service  computer  system  will  be  physically  moved  from 
NIST  to  COS  headquarters,  where  COS  will  be  responsible  for  the 
day-to-day  operation.  COS  plans  to  connect  the  T&R  service  end 
system  directly  to  the  AT&T  network. 


2.2  The  T&R  Service  Hardware 

The  T&R  service  computer  system  has  two  fixed  disks  for  data 
storage.  The  data  backup  capability  of  this  system  is  supported 
with  two  tape  units.  The  T&R  service  system  has  modem  connections 
with  at  least  two  phone  lines  supported  simultaneously  for 
asynchronous  access.  The  modems  operate  in  asynchronous, 
full-duplex  mode  at  speeds  of  2400/1200  bits/second  with  no  parity, 
8 bits,  and  1 stop  bit. 

The  T&R  service  system  uses  a laser  printer  for  T&R  service 
correspondence  and  for  hard  copy  distributions  of  the  information 
contained  in  the  T&R  service  database. 
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2.3  The  T&R  Service  Dateibase  Management  System 

The  T&R  service  database  uses  Version  6 of  ORACLE  Corporation's 
Relational  Database  Management  System  (RDBMS) . ORACLE  uses 
Structured  Query  Language  (SQL) , the  ANSI  and  IBM  standard  language 
for  database  management.  ORACLE  provides  application  development 
tools  to  assist  developers  in  building  applications.  The 
application  development  tools  used  by  the  T&R  service  are  listed 
below,  along  with  a brief  description  of  each  tool: 

* SQL*ReportWriter  - allows  users  to  create  formatted 
multi-part  reports. 

* SQL*Forms  - is  a 4th  generation  tool  that  allows  users 
to  develop  forms -based  applications. 

* SQL*Plus  - is  a 4th  gener  tion,  interactive  interface. 

The  user  enters  SQL  state.  - ^nts  as  interactive  commands 
and  SQL*Plus  runs  them  against  the  user's  ORACLE 
database. 

* SQL*Menu  - allows  users  to  develop  custom  menu- 
driven  interfaces  to  their  ORACLE  applications  and 
other  products. 

ORACLE  also  provides  programmatic  interfaces  which  allow 
programmers  to  access  ORACLE  data  from  within  standard  programming 
languages.  The  T&R  service  uses  ORACLE'S  Pro*C  programmatic 
interface.  This  programmatic  interface  supports  the  C programming 
language. 


3.  The  T&R  Service  Functions,  Operations,  and  Datedsase 

The  OSINET  Testing  & Registration  project  operates  in  the  following 
manner.  Testing  parties  privately,  voluntarily,  and  bilaterally 
agree  to  perform  certain  interoperation  tests.  The  successful 
results  of  these  tests  are  registered  with  the  T&R  service.  The 
following  sections  describe  the  design  and  operation  of  the  T&R 
service.  The  sections  discuss  items  such  as  the  electronic  forms 
used,  the  structure  of  the  database,  and  the  access  methods 
provided. 


3.1  The  T&R  Service  Audience 

The  T&R  service  serves  the  needs  of  two  different  groups,  T&R 
registrants  and  T&R  users.  A T&R  registrant  is  an  organization 
that  is  permitted,  under  the  rul^s  established  by  OSINET,  to 
register  interoperability  test  r ilts.  The  T&R  users  are 
individuals  who  query  the  database  view  its  contents.  T&R  users 
may  be  anyone;  to  access  the  T&R  service  for  queries  users  do  not 


2 


have  to  be  OSINET  members.  For  further  definition  of  who  is 
eligible  to  register  information  with  the  T&R  service,  please  refer 
to  OSINET  Corporation  General  Agreements  and  Information  Document. 

section  4.2. 


3.2  The  Forms  Used  by  the  T&R  Service 

The  results  of  successful  interoperability  testing  are  registered 
by  T&R  registrants  using  an  electronic  version  of  the  Declaration 
of  Interoperation  (DI) . The  results  are  stored  in  pairs  with  a 
matching  unique  identifier  in  the  T&R  service's  relational 
database.  Users  are  able  to  retrieve  information  on  the  testing 
results  of  products  that  is  contained  in  the  DI  using  the 
asynchronous  access  method. 


3.3  The  T&R  Service  Access  Methods 

The  T&R  service  allows  users  to  make  basic  queries  to  its 
relational  database.  The  T&R  service  also  allows  T&R  registrants 
to  register  testing  results  in  the  database.  These  two  services 
are  available  thru  the  T&R  service  communication  architecture, 
which  is  based  on  three  different  access  methods.  The  access 
methods  are  asynchronous  terminal  access  via  phone  line  modem. 
Packet  Assembler/Disassembler  (PAD)  access  via  OSINET,  and  MHS  via 
OSINET.  Figure  1 shows  the  T&R  service  communication  architecture. 


PIIOME 

LINE 


Figure  1.  The  T&R  Service  Communication  Architecture 
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3.4  The  T&R  Service  Entries 

The  T&R  service  data  may  be  used  to  assist  users  in  their 
procurement  efforts.  It  provides  up-to-date  information  on 
announced  OSI  products  that  interoperate.  Only  implementations 
that  have  met  the  OSINET  testing  criteria  are  listed. 

T&R  entries  do  not  contain  any  confidential  information.  T&R 
entries  may  be  accessed  online  by  OSINET  members  and  potential 
customers,  at  no  charge.  The  information  may  also  be  published 
periodically  with  the  cost  of  the  hard  copy  version  of  the  T&R 
information  being  paid  by  the  user. 

T&R  entries  become  publically  available  and  may  not  be  deleted. 
Correct  entries  applicable  to  announced  products  are  known  as 
"CURRENT"  entries.  Entries  found  to  be  in  error  are  marked  as 
"INVALID".  Entries  that  are  retired,  for  example  because  of  new 
releases  of  products,  are  marked  "OBSOLETE".  New  entries,  known 
as  "DRAFT"  entries,  may  be  edited  by  the  submitter  to  correct 
typographical  or  other  errors. 

"DRAFT"  and  "INVALID"  entries  are  not  accessible  to  users.  Entries 
which  have  been  marked  "OBSOLETE"  are  available  for  up  to  two 
years . 

The  organization  submitting  an  entry  to  the  database  retains  all 
patents  and  copyrights.  No  patent  or  copyright  licenses,  expressed 
or  implied,  are  granted  by  these  submissions. 


3.5  The  T&R  Service  Declaration  of  Interoperation  (DI)  Database 
Design 

The  T&R  service  utilizes  three  databases  for  DI  data:  a WORKING 
database,  a PERMANENT  database,  and  an  EXAMPLE  database.  This 
design  was  chosen  to  increase  the  protection,  simplify  the 
operation,  and  improve  the  integrity  of  the  T&R  service.  The 
following  paragraphs  describe  each  of  the  databases  and  how  they 
are  used  by  the  T&R  service. 

The  WORKING  database  is  used  by  T&R  registrants  when  they  are 
registering  test  results.  The  T&R  registrants  register  the  test 
results  as  "DRAFT"  entries  in  the  WORKING  database.  The  T&R 
registrants  may  make  changes  to  their  entries  in  this  database 
while  the  status  of  the  entry  is  "DRAFT".  Once  T&R  registrants 
change  the  status  of  an  entry  from  "DRAFT"  to  "CURRENT"  they  are 
unable  to  make  further  changes  to  their  entry  in  the  WORKING 
database. 

The  PERMANENT  database  is  used  t ’ T&R  users  when  they  are  query* ig 
the  database.  The  PERMANENT  da^.  ibase  may  also  be  accessed  by  T&R 
registrants  to  change  the  status  of  an  entry  from  "CURRENT"  to 
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"INVALID"  or  "OBSOLETE".  T&R  registrants  may  also  make  changes  to 
derived  systems  and  marketing  contact  information  on  a "CURRENT" 
entry. 

Once  the  status  of  the  matching  entries  in  the  WORKING  database  is 
"CURRENT",  an  automated  T&R  service  routine  moves  the  matching 
entries  from  the  WORKING  database  to  the  PERMANENT  database  to  be 
available  for  viewing  by  T&R  users.  The  T&R  service  database 
design  thus  allows  only  T&R  registrants  to  have  access  to  the 
WORKING  database.  It  does  not  allow  users  to  access  entries  in  the 
WORKING  database. 

The  EXAMPLE  database  is  a sample  database  provided  as  a means  for 
registrants  and  users  to  familiarize  themselves  with  the  T&R 
service  operation.  Inexperienced  users  and  registrants  are 
encouraged  to  "play"  with  the  EXAMPLE  database  before  using  the 
"real"  database. 


3.6  Additional  T&R  Service  Databases 

There  are  several  other  databases  used  by  the  T&R  service  in 
addition  to  the  DI  databases.  The  first  database  is  known  as  the 
"Test  Requirements  Specification"  database.  This  database  contains 
an  entry  for  each  profile  which  may  appear  in  the  profiles 
referenced  section  of  the  DI  (please  see  Figure  10  or  17) . Each 
profile  developer  may,  for  each  OSI  application,  specify  the  subset 
of  interoperability  tests  which  must  be  successfully  completed  to 
satisfy  the  requirements  of  the  profile  developer.  An  entry  in  the 
Test  Requirements  Specification  database  consists  of  the  name  of 
the  profile  (e.g.  US  GOSIP  Ver.  1 MHS)  and  the  list  of  OSINET  test 
cases  associated  with  that  profile. 

Another  database  used  by  the  T&R  service  is  the  "Detailed  Test 
Results"  database.  Each  registered  DI  makes  reference  to  this 
database.  Each  detailed  test  results  entry  lists  only  those  test 
cases  successfully  executed  between  the  test  partners. 


3.7  The  T&R  Service  Paper  Response  Process 

The  T&R  service  provides  a positive  acknowledgement  for  every 
transaction  which  modifies  either  the  PERMANENT  or  WORKING 
database.  This  positive  acknowledgement  is  in  the  form  of  a 
letter.  The  letter  contains  information  on  the  change  made,  who 
(as  far  as  the  database  is  concerned)  executed  the  change,  and  the 
current  view  of  the  data  as  it  appears  in  the  database. 

The  letter  is  generated  by  ORACLE'S  SQL*ReportWriter . Upon  logging 
in  to  the  electronic  DI  form,  the  username/password  used  by  the  T&R 
registrant  is  recorded.  By  use  of  the  username/password  the 
database  identifies  who  made  the  change.  This  username/  password 
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is  also  used  by  the  SQL*ReportWriter  to  retrieve  from  the 
Registrant  Information  table  the  name  and  address  of  the  person  to 
receive  the  letter  detailing  the  change  accepted  to  the  database. 

In  this  way,  a paper  trail  exists  for  every  entry  in  the  database. 
This  paper  trail  adds  to  the  overall  T&R  service  protection.  For 
example,  consider  what  happens  if  another  T&R  registrant 
masquerades  as  ABC  Company  and  makes  a change  to  one  of  ABC 
Company's  entries.  When  the  database  generates  the  letter  noting 
the  change  made,  it  designates  ABC  Company  as  the  recipient, 
because  as  far  as  the  database  is  concerned,  ABC  Company  made  the 
change.  As  soon  as  ABC  Company  receives  the  letter,  it  knows  that 
its  entries  have  been  tampered  with. 

In  cases  where  a change  made  to  an  entry  may  affect  the  matching 
entry,  both  testing  partners  receive  notice  of  the  change.  For 
example  when  ABC  Company  changes  the  status  of  its  X.400  entry  from 
"CURRENT"  to  "INVALID"  or  "OBSOLETE",  ABC  Company's  testing 
partner,  XYZ  Inc.,  is  also  sent  a letter  noting  the  change. 


3.8  The  T&R  Service  Directory  Information  Function 

The  T&R  service  offers  the  option  of  directory  information.  The 
directory  information  provides  a brief  overview  of  the  data  stored 
in  the  database.  The  directory  information  consists  of  a list  of 
registrants  who  have  products  registered  and  a list  of  the  products 
registered  with  the  database.  Registration  of  test  results  is  open 
to  OSINET  Corporation  Senior  Members. 


3.9  The  T&R  Service  Backup  Process 

Once  every  two  weeks,  the  automated  backup  process  makes  a backup 
copy  of  the  database.  During  this  process  entries  which  have  had 
a status  of  "OBSOLETE"  for  two  years  or  more  are  extracted  from  the 
database  and  archived  on  a tape.  Entries  which  have  a status  of 
"INVALID"  are  also  extracted  and  archived.  T&R  registrants  or 
users  who  wish  to  view  archived  entries  must  make  a special  request 
to  the  T&R  service. 

Special  requests  may  be  made  by  sending  an  electronic  mail  message, 
sending  a letter,  or  telephoning  the  T&R  service  support  staff. 
The  T&R  service  support  staff  will  manually  extract  the  requested 
entries  and  send  them  back  to  the  requesting  party. 

The  T&R  service  support  staff  provides  classifications  for  special 
requests.  If  a special  request  is  "CRITICAL",  the  T&R  service 
support  st'’ :f  will  respond  within  48  hours.  If  the  request  is 
"IMPORTANT  the  T&R  service  staff  will  respond  withi  1 week.  All 
other  requ<  .viCs,  known  as  "NORMAL"  requests  will  be  a ^wered  within 
2 weeks . 
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3.10  The  T&R  Service  Dateibase  TaUsles 

The  T&R  service  makes  use  of  eleven  major  tables.  Three  of  the 
tables  are  similar  in  content.  The  three  main  tables,  referred  to 
as  "DI”  tables,  correspond  with  the  WORKING,  PERMANENT,  and  EXAMPLE 
databases.  The  fourth  table  is  the  username/password  table, 
referred  to  as  the  "Registrant  Information"  table.  The  Registrant 
Information  table  contains  the  T&R  registrant  usernames  and 
passwords  associated  with  registering  or  changing  data  in  the  above 
mentioned  databases.  The  Registrant  Information  table  also 
contains  the  names,  addresses,  and  telephone  numbers  of  the  main 
contacts  for  each  T&R  registrant. 

The  fifth  table  is  known  as  the  "Test  Requirements  Specification" 
table.  This  table  contains  an  entry  for  each  of  the  profiles  which 
may  be  specified  in  the  profiles  referenced  of  the  DI  (please  see 
Figure  10  or  17)  . Each  entry  contains  the  profile  name  and  the 
list  of  test  cases  associated  with  that  profile.  The  T&R  service 
support  staff  is  responisible  for  updating  this  table,  using 
information  supplied  by  responsible  organizations.  NIST  for 
example  will  specify  the  tests  that  apply  to  the  GOSIP  profile. 

The  sixth  and  seventh  tables,  known  as  "Profiles  Referenced"  and 
"Example  Profiles  Referenced",  are  similar  in  nature.  The  table, 
"Profiles  Referenced",  corresponds  to  the  PERMANENT  and  WORKING 
databases.  The  table,  "Example  Profiles  Referenced",  corresponds 
to  the  EXAMPLE  database.  Each  of  these  tables  contain  the  list  of 
profiles  associated  with  each  DI  entry.  This  data  is  kept  in 
separate  tables  from  the  other  DI  data  in  order  to  allow  for  an 
unbounded  number  of  entries  per  DI.  These  tables  are  linked  to  the 
DI  tables  through  the  unique  ID  assigned  to  each  DI  entry. 

The  eighth  and  ninth  tables  contain  lists  of  test  cases.  These 
tables  are  known  as  the  "Detailed  Test  Results"  table  and  the 
"Example  Detailed  Test  Results"  table.  Once  again,  one  table, 
"Detailed  Test  Results",  corresponds  to  the  PERMANENT  and  WORKING 
databases,  while  the  other,  "Example  Detailed  Test  Results", 
corresponds  to  the  EXAMPLE  database.  These  tables  contain  one 
entry  per  DI  and  each  entry  lists  all  test  cases  successfully 
executed  between  the  partners;  including  tests  that  are  in  addition 
to  those  required  by  the  listed  profiles.  These  tables  are  linked 
to  the  DI  tables  through  the  unique  ID  assigned  to  each  DI  entry. 

The  last  two  tables,  referred  to  as  "Derived  Systems"  and  "Example 
Derived  Systems",  contain  the  derived  systems  data  associated  with 
each  DI  entry.  Derived  systems  data  is  stored  in  separate  tables 
to  allow  multiple  entries  for  any  one  DI  entry.  These  tables  are 
updated  by  the  registrants.  When  a registrant  makes  a change  to 
the  "Derived  Systems"  table,  the  test  partner  is  notified  that 
additional  changes  have  been  made  to  the  derived  systems  data. 
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These  tables  are  linked  to  the  DI  tables  through  the  unique  ID 
assigned  to  each  DI  entry.  And  once  again,  one  table,  "Derived 
Systems”,  corresponds  to  the  PERMANENT  and  WORKING  databases,  while 
the  other  table,  "Example  Derived  Systems”,  corresponds  to  the 
EXAMPLE  database. 

The  DI  tables  contain  the  information  on  the  Declaration  of 
Interoperation.  The  DI  fields,  their  type,  and  length  are  listed 
in  Table  1. 


Name 


UNIQUE_RECORD_ID 

REGISTRANT_IDENTIFICATION 

IDENTIFICATION_NUMBER 

ENTRY_DATE 

STATUS 

TEST_PARTY_A 

A_SUBMITTED_BY 

TEST_PARTY_B 

B_SUBMITTED_BY 

PRODUCT_SPECIFICATION 

HARDWARE_PLATFORM 

OPERATING_SYSTEM 

APPLICATION_PROFILE 

APPLI CAT I ON_PRO F I LE_2 

APPLICATI0N_PR0FILE_3 

TRANS PORT_PROFI LE 

RELAY_PROFILE 

INTERCHANGE^!  ILE 

CONTACT_NAME 

CONTACT_ADDRI 

C0NTACT_ADDREoo2 

CONTACT_CITY 

CONTACT_STATE 

CONTACT_Z I P_CODE 

CONT ACT_TE  LE  PHONE 

CONTACT_FAX 

PICS_NUMBER 

TSES_NUMBER 

PITR_NUMBER 

TEST  SUITE  IDENTIFICATION 


Null  ? Type 


NOT  NULL  NUMBER (9) 

NOT  NULL  NUMBER (7) 

NOT  NULL  CHAR (18) 

DATE 
CHAR(IO) 
CHAR(50) 
CHAR(50) 
CHAR(50) 
CHAR(50) 
CHAR(IOO) 
CHAR(30) 
CHAR(30) 
CHAR(7) 
CHAR(7) 
CHAR(7) 
CHAR(7) 
CHAR(ll) 
CHAR  (7) 
CHAR(40) 
CHAR(40) 
CHAR(40) 
CHAR(30) 
CHAR(2) 
CHAR(IO) 
CHAR(20) 
CHAR(20) 
CHAR(20) 
CHAR(20) 
CHAR(20) 
CHAR(IOO) 


Taible  1.  The  DI  Ted^le  Definition 
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Table  2 shows  the  structure  of  the  Registrant  Information  table. 
This  table  is  only  viewable  by  persons  with  Database  Administrator 
(DBA)  privilege.  Entries  are  put  into  the  Registrant  Information 
table  when  the  DBA  grants  an  T&R  registrant  access  to  the  T&R 
service  databases. 


Name 

Null  ? 

Type 

COMPANY  NAME 

CHAR(50) 

USERNAME 

CHAR (20) 

PASSWORD 

CHAR(20) 

CONTACT  NAME 

CHAR (35) 

CONTACT  ADDRESS 1 

CHAR(40) 

CONTACT  ADDRESS 2 

CHAR(40) 

CONTACT  CITY 

CHAR(30) 

CONTACT  STATE 

CHAR(2) 

CONTACT  COUNTRY 

CHAR(25) 

CONTACT  ZIP  CODE 

CHAR(IO) 

CONTACT  TELEPHONE 

CHAR(20) 

CONTACT  FAX 

CHAR(20) 

IDENTIFICATION  NUMBER 

NOT  NULL 

NUMBER(7) 

Table  2.  The  Registrant  Information  Table  Definition 


Table  3 shows  the  structure  of  the  Test  Requirements  Specification 
table. 


Name 

Null? 

Type 

PROFILE  NAME 

CHAR(IOO) 

TEST  SUITE  IDENTIFICATION 

CHAR(IOO) 

TEXT  AREA  1 

CHAR(60) 

TEXT  AREA  2 

CHAR(60) 

TEXT  AREA  3 

CHAR(60) 

TEXT  AREA  4 

CHAR(60) 

TEXT  AREA  5 

CHAR(60) 

TEXT  AREA  6 

CHAR(60) 

TEXT  AREA  7 

CHAR(60) 

TEXT  AREA  8 

CHAR(60) 

TEXT  AREA  9 

CHAR(60) 

TEXT  AREA  10 

CHAR(60) 

TEXT  AREA  11 

CHAR(60) 

TEXT  AREA  12 

CHAR(60) 

Table  3.  The  Test  Requirements  Specification  Tedsle 
Definition 
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Table  4 shows  the  format  of  the  Profiles  Referenced  tables. 
Name  Null?  Type 


SDI_UNIQUE_RECORD_ID  NOT  NULL  NUMBER (9) 
PROFILE_REFERENCED  CHAR ( 100 ) 
COMPANY_IDENTIFICATION_NUMBER  NOT  NULL  NUMBER (7) 

Table  4.  The  Profiles  Referenced  T2Lble  Definition 


Table  5 shows  the  structure  of  the  Detailed  Test  Results  tables 


Name 

Null? 

Type 

SDI  UNIQUE  RECORD  ID 

NUMBER (9) 

TEXT  AREA  1 

CHAR(75) 

TEXT  AREA  2 

CHAR(75) 

TEXT  AREA  3 

CHAR(75) 

TEXT  AREA  4 

CHAR(75) 

TEXT  AREA  5 

CHAR(75) 

TEXT  AREA  6 

CHAR(75) 

TEXT  AREA  7 

CHAR(75) 

TEXT  AREA  8 

CHAR(75) 

TEXT  AREA  9 

CHAR(75) 

TEXT  AREA  10 

CHAR(75) 

TEXT  AREA  11 

CHAR(75) 

TEXT  AREA  12 

CHAR(75) 

TEXT  AREA  13 

CHAR(75) 

COMPANY  IDENTIFICATION  NUMBER 

NOT  NULL 

NUMBER (7) 

Tcd^le  5.  The  Detailed  Test  Results  TadDle  Definition 


Table  6 shows  the  structure  of  the  Derived  Systems  tables. 
Name  Null?  Type 


SDI_UNIQUE_RECORD_ID 

PRODUCT_SPECIFICATION 

HARDWARE_PLATFORM 

OPERATING_SYSTEM 

APPLICATION_PROFILE 

APPLI CAT I ON_PRO F I LE_2 

APPLICATI0N_PR0FILE_3 

TRANS  PORT_PROFI LE 

RELAY_PROFILE 

INTERCHANGE_PROFILE 

COMPANY  IDENTIFICATION  NUMBER 


NOT  NULL  NUMBER (9) 
CHAR(50) 
CHAR(30) 
CHAR(30) 
CHAR(7) 
CHAR(7) 
CHAR(7) 
CHAR(7) 
CHAR(ll) 
CHAR(7) 

NOT  NULL  NUMBER (7) 


Table  6.  The  Derived  Systems  Tedsle  Definition 
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New  fields  may  be  added  or  the  size  of  a field  may  be  increased  at 
a future  time.  Changing  the  tables  in  this  manner  can  be  made 
without  affecting  the  resident  data. 


4.  The  T&R  Service  Asynchronous  Access  Method 

All  users  wanting  to  communicate  with  T&R  service  using  the 
asynchronous  access  method  must  have  a computer  with  dial-out 
capabilities,  a modem  that  enables  a 2400/1200  bits/second 
full-duplex  mode  data  transfer,  and  a software  package  that 
establishes  the  link,  synchronizes  the  communication  between  the 
two  hosts,  and  provides  emulation  of  a Digital 
VT100/VT220/VT330/VT340  teminal  type.  The  login  process  consists 
of  the  following  steps. 

The  first  step  is  to  establish  a communication  link  between  the  T&R 
service  computer  and  the  user's  computer.  The  user's  computer 
initiates  the  connection  by  dialing  the  phone  number  of  the  T&R 
service  computer.  The  T&R  service  computer  responds  by  accepting 
the  connection.  The  user's  computer  announces  the  establishment 
of  a successful  communication  link  with  a prompt  (examples: 
"CONNECT",  two  bells,  or  both) . At  this  point,  pressing  the  RETURN 
key  several  times  causes  the  user's  computer  to  display  the  login 
information  screen. 

The  next  step  is  to  enter  the  login  information.  The  username 
"NRS_M0DEM"  must  be  entered  followed  by  a carriage  return.  The  T&R 
service  computer  remote  host  responds  by  transmiting  the  "TESTING 
& REGISTRATION  (T&R)  SERVICE  LOGIN  MENU"  screen  shown  in  Figure  2. 

+ + 


' TESTING  & REGISTRATION  (T&R)  SERVICE  LOGIN  MENU 


Select  option  by  number 


0 — > Quit  1 — > User  2 — > T&R  Registrant 


Enter  Option  Number  ===>  : 

I 

+ 


I 

+ 


Figure  2.  The  T&R  Servic  Login  Menu 
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Users  select  option  1 to  access  test  results.  T&R  service 
registrants  select  option  2 to  access  or  update  test  results. 
Users  select  option  0 to  terminate  T&R  service  access.  After 
selecting  option  1,  the  menu  shown  in  Figure  3 is  displayed;  after 
selecting  option  2,  the  menu  shown  in  Figure  4 is  displayed. 


4 . 1 The  T&R  Service  Menus 

Figure  3 shows  the  menu  presented  when  option  1 is  selected.  This 
is  the  T&R  user  menu  and  it  contains  5 options.  Selecting  the 
first  option  brings  up  the  EXAMPLE  database  menu  which  will  give 
registrants  and  users  a tool  to  learn  how  to  update  and  access  test 
result  information  in  the  PERMANENT  database.  Selecting  the  second 
option  enables  the  user  to  view  the  information  in  the  PERMANENT 
database.  The  HELP  option  causes  "help”  text  to  be  displayed.  The 
fourth  option  provides  the  Directory  Information.  Selecting  the 
last  option  causes  the  termination  of  the  T&R  service  work  session. 

-f + 

I I 

THE  TESTING  & REGISTRATION  (T&R)  SERVICE 
====>  USER  MENU  <==== 


— > 1 EXAMPLE  Database 

2 Query  Test  Results 

3 HELP 

4 Directory  Information 

5 EXIT 


Make  your  choice:  _ 

For  Quick  Help  Press  ================>  Esc  - K 

I 


Figure  3.  The  T&R  User  Menu 


Figure  4 shows  the  menu  presented  when  option  2 in  Figure  2 is 
selected.  This  is  the  main  menu  for  T&R  registrants  and  it 
contains  an  additional  option  to  register  or  update  test  results. 

There  is  also  a quick  help  screen  available  at  each  menu  level 
(pressing  Escape  k displays  a help  menu) . The  quick  help  menu 
reminds  users  of  the  keystrokes  necessary  to  negotiate  through  the 
menu  driven  application,  such  as  moving  the  cursor  up,  down,  left 
and  right,  returning  to  the  previous  menu  and  returning  tc  the  main 
menu. 
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The  second  option  brings  up  the  submenu  for  registrations  and 
updates  shown  in  Figure  5.  This  submenu  contains  6 options  that 
the  T&R  registrant  can  select  by  simply  moving  the  cursor  up  or 
down.  Once  the  selection  is  made,  the  registrant  presses  the 

RETURN  key  to  execute  the  transaction  corresponding  to  that 
option. 

+ + 

I I 

THE  TESTING  & REGISTRATION  (T&R)  SERVICE  j 

====>  REGISTRANT  MENU  <====  ! 


1 EXAMPLE  Database 
— > 2 Register/Update  Test  Results 

3 Query  Test  Results 

4 HELP 

5 Directory  Information 

6 EXIT 


Make  your  choice:  _ 

For  Quick  Help  Press  ================>  Esc  - K 

I 1 


Figure  4.  The  T&R  Registrant  Menu 


Any  one  of  the  first  four  options  brings  up  the  username/password 
screen  which  is  the  first  page  of  the  registrants  DI  form.  T&R 
registrants  must  have  their  usernames  and  passwords  validated 
before  registering  test  result  information  in  the  WORKING  database. 
After  this  information  is  validated,  page  2 of  the  T&R  registrant 
DI  form  is  displayed  for  registration. 

The  first  option  allows  T&R  registrants  to  register  successful  test 
results  or  to  update  an  entry  that  is  currently  in  "DRAFT"  status. 
Updates  are  not  permitted  in  the  WORKING  database  after  the  entry 
is  changed  to  "CURRENT"  status.  The  second  option  enables  T&R 
registrants  to  change  the  status,  marketing  contact  or  derived 
systems  information  of  "CURRENT"  entries  in  the  T&R  service 
PERMANENT  database.  The  third  option,  allows  T&R  registrants  to 
register  detailed  test  results  data.  The  fourth  option  enables  T&R 
registrants  to  change  their  passwords.  Option  five  returns  the  T&R 
registrant  to  the  previous  menu  and  option  six  terminates  the  T&R 
service  menu-driven  work  session. 
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+ 

I 


REGISTRATIONS  AND  UPDATES 


+ 

I 


====>  SUB  MENU  <==== 


1 Register/Update  "DRAFT”  DI 

2 Update  "CURRENT"  DI 

— > 3 Register  Detailed  Test  Results 

4 Change  Password 

5 Previous  Menu 

6 EXIT 

Make  your  choice:  _ 

For  Quick  Help  Press  ================>  Esc  - K 

I 


Figure  5.  The  Registrations  and  Updates  Submenu 


4.2  Using  the  T&R  Service  DI  Forms  Application 

The  T&R  registrants  and  users  access  the  database  through  an 
electronic  version  of  the  DI.  An  expanded  version  of  the  DI  form 
is  provided  for  T&R  registrants  to  protect  against  unauthorized 
access  to  their  entries. 

Access  to  the  electronic  form  is  provided  by  an  DI  application. 
The  DI  application  controls  the  actions  allowed  on  the  database  and 
the  types  of  data  stored  in  any  given  field. 

T&R  registrants  and  users  use  either  function  keys  or  alternate 
keypads  to  enter  data  on  the  form.  For  more  information  on  the 
terminal  types  supported  and  their  keypad  layouts,  please  refer  to 
sections  4.3  and  4.4. 

The  DI  forms  provided  for  the  T&R  registrants  and  users  consist  of 
several  pages.  Whenever  a T&R  registrant  or  user  is  presented  with 
an  DI  form,  initially  page  1 is  visible.  At  the  very  bottom  of 
each  screen,  a T&R  registrant  or  user  sees  a "help"  line.  In  this 
"help"  line,  informational  messages  and  error  messages  are 
displayed.  Additional  "help"  information  can  be  displayed  by 
pressing  the  "HELP"  key. 

Since  the  DI  forms  consist  of  several  pages  the  T&R  registrants  and 
users  must  use  the  "NEXT  BLOCK"  key  to  page  down,  and  the  "PREVIOUS 
BLOCK"  key  to  page  up.  The  T&R  users'  DI  form  consists  of  6 pages, 
while  the  T&R  registrants'  DI  form  is  8 pages  in  length.  Figures 
6-11  show  the  exact  format  of  the  T&R  users'  DI  form.  Figures 
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12  - 19  show  the  exact  format  of  the  T&R  registrants'  DI  form.  In 
both  sets  of  figures  the  EXAMPLE  database  version  of  the  forms  is 
used.  The  forms  look  the  same  for  both  the  WORKING  and  PERMANENT 
databases  except  for  the  text  headers  which  identify  the  database 
being  accessed. 

In  some  fields,  the  data  entered  may  be  restricted  to  a predefined 
list  of  values.  In  this  case,  the  T&R  registrant  or  user  is 
notified  when  the  data  entered  is  not  a valid  response.  The  T&R 
registrant  or  user  is  then  instructed  to  check  the  list  of  legal 
field  values  by  pressing  "ESCAPE  V".  The  T&R  registrant  or  user 
then  presses  the  TAB  key  to  cycle  through  the  list  of  available 
responses  till  he/she  finds  the  desired  choice.  When  the  T&R 
registrant  or  user  has  found  the  desired  data,  pressing  the  PF4  or 
"CANCEL/EXIT"  key  deactivates  the  list  of  field  values. 


DECLARATION  OF  INTEROPERATION 


I Nature  of  Interoperation  Testing  I 

I I 

I The  purpose  of  interoperation  testing  is  to  increase  the  probability  that  1 
I different  implementations  can  interwork.  However,  the  complexity  of  OSI  1 
1 protocols  makes  exhaustive  testing  impractical  on  both  technical  and  1 

1 economic  grounds.  Furthermore,  there  is  no  guarantee  that  a system  under  1 

1 TEST  WHICH  HAS  PASSED  ALL  THE  RELEVANT  TESTS  CONFORMS  TO  A SPECIFICATION.  I 

1 Neither  is  there  any  guarantee  that  such  a system  under  test  will  interwork  1 

I WITH  OTHER  REAL  OPEN  SYSTEMS.  RaTHER,  THE  PASSING  OF  THE  TESTS  GIVE  CONFI-  I 
I DENCE  THAT  THE  SYSTEM  UNDER  TEST  HAS  THE  STATED  CAPABILITIES  AND  THAT  ITS  ! 

I BEHAVIOR  CONFORMS  CONSISTENTLY  IN  REPRESENTATIVE  INSTANCES  OF  COMMUNICATION. 1 

i I 

I Limits  and  Reservations  ! 

I j 

I This  OSINET  Network  Registration  Service  entry  is  publicly  available.  No  ! 

1 PATENT  NOR  COPYRIGHT  LICENSES,  EXPRESSED  OR  IMPLIED,  ARE  GRANTED  BY  THIS  1 

I SUBMISSION.  I 

+ 


Figure  6.  Page  1 of  the  T&R  Service  User  DI 
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+ 


DECLARATION  OF  INTEROPERATION 

The  information  below  details  the  status  of  this  entry,  the  date  it  was 

ENTERED,  THE  PARTIES  INVOLVED  IN  THE  TESTING,  AND  TEST  PARTY  A'S  PRODUCT 

tested.  The  fields  on  the  remaining  pages  refer  to  test  party  A's  product. 
Identification  # 


Status  Entry  Date 


Test  Party  A 
Submitted  By 


Test  Party  B 
Submitted  By 


1 Product  Specification  I 

+ + 


Figure  ?•  Page  2 of  the  T&R  Service  User  DI 


PRODUCT  INFORMATION 


The  information  below  describes  the  environment  in  which  the 
testing  was  conducted,  i.e.  the  hardware  platform,  operating 
SYSTEM  and  associated  OSI  PROFILES  USED  BY  TEST  PARTY  A. 

Hardware  Platform  

Operating  System  

Application  Profile  1 

2 

3 

Transport  Profile  

Relay  Profile  

Interchange  Profile  


Figure  8.  Page  3 of  the  T&R  Service  User  DI 
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+ 


+ 


MARKETING  CONTACT  INFORMATION  FOR  COMPANY  A'S  PRODUCT 

Name  

Address  Line  1 

Address  Line  2 

City  State  ZIP  Code  _ 

Telephone  FAX  

SUPPORTING  DOCUMENTATION  ASSOCIATED  WITH  THE  TESTING 

PICS  # TSES  # 

PITR  # 

Test  Suite  ID  


Figure  9.  Page  4 of  the  T&R  Service  User  DI 


Profiles  Referenced 


This  entry  demonstrates  interoperation  according 

TO  THE  PROFILES  LISTED  BELOW.  ThE  TESTS  REQUIRED 
TO  DEMONSTRATE  INTERWORKING  MAY  BE  FOUND  IN  THE 

Test  Requirements  Specifications  corresponding  to 

THE  PROFILES  LISTED  BELOW. 

Profile  Referenced: 


Figure  10.  Page  5 of  the  T&R  Service  User  DI 
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+ 


DERIVED  SYSTEMS 


+ 


The  information  listed  below  describes  a product/system  which 

COMPANY  A HAS  IDENTIFIED  AS  A DERIVATIVE  OF  THE  TESTING  PERFORMED. 

Product  Specification  

Hardware  Platform  

Operating  System  

Application  Profile  1 ____  

2 

3 


Transport  Profile 


Relay  Profile 


I Interchange  Profile  I 

+ + 


Figure  11.  Page  6 of  the  T&R  Service  User  DI 
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+ 


1 , DECLARATION  OF  INTEROPERATION  1 

I Nature  of  Interoperation  Testing  I 

I 1 

I The  purpose  of  interoperation  testing  is  to  increase  the  probability  that  1 
1 different  implementations  can  interwork.  However,  the  complexity  of  OSI  ! 

I protocols  makes  exhaustive  testing  impractical  on  both  technical  and  I 

I ECONOMIC  GROUNDS.  FURTHERMORE,  THERE  IS  NO  GUARANTEE  THAT  A SYSTEM  UNDER  I 

1 TEST  WHICH  HAS  PASSED  ALL  THE  RELEVANT  TESTS  CONFORMS  TO  A SPECIFICATION.  1 

I Neither  is  there  any  guarantee  that  such  a system  under  test  will  interwork  I 

I WITH  OTHER  REAL  OPEN  SYSTEMS.  RaTHER,  THE  PASSING  OF  THE  TESTS  GIVE  CONFI-  i 
I DENCE  THAT  THE  SYSTEM  UNDER  TEST  HAS  THE  STATED  CAPABILITIES  AND  THAT  ITS  i 
I BEHAVIOR  CONFORMS  CONSISTENTLY  IN  REPRESENTATIVE  INSTANCES  OF  COMMUNICATION. 1 

I I 

I Limits  and  Reservations  i 

I ! 

1 This  OSINET  Network  Registration  Service  entry  is  publicly  available.  No 
1 patent  nor  copyright  licenses,  expressed  or  implied,  are  granted  by  this  I 

I SUBMISSION.  1 

+ + 


Figure  12.  Page  1 of  the  T&R  Service  Registrant  DI 


+ 


Registrant's  Login  Information 


Company  Name 


+ 


I 

i 


I 


I 


Username 

Password 


+ 


+ 


Figure  13.  Page  2 of  the  T&R  Service  Registrant  DI 
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+ 


DECLARATION  OF  INTEROPERATION 

The  information  below  details  the  status  of  this  entry,  the  date  it  was 

ENTERED,  THE  PARTIES  INVOLVED  IN  THE  TESTING,  AND  TEST  PARTY  A'S  PRODUCT 
TESTED.  The  fields  on  the  REMAINING  PAGES  REFER  TO  TEST  PARTY  A'S  PRODUCT. 

Identification  # 


Status  Entry  Date 


Test  Party  A 
Submitted  By 

Test  Party  B 
Submitted  By 


I Product  Specification  I 

+ + 


Figure  14.  Page  3 of  the  T&R  Service  Registrant  DI 


PRODUCT  INFORMATION 

The  information  below  describes  the  environment  in  which  the 

TESTING  WAS  CONDUCTED,  I.E.  THE  HARDWARE  PLATFORM,  OPERATING 

system  and  associated  OSI  profiles  used  by  test  party  a. 

Hardware  Platform  

Operating  System  

Application  Profile  1 

2 

3 


Transport  Profile 


Relay  Profile 


Interchange  Profile 


Figure  15.  Page  4 of  the  T&R  Service  Registrant  DI 
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+ 


+ 


MARKETING  CONTACT  INFORMATION  FOR  COMPANY  A'S  PRODUCT 

Name  

Address  Line  1 

Address  Line  2 

City  State  ZIP  Code  _ 

Telephone  FAX  

SUPPORTING  DOCUMENTATION  ASSOCIATED  WITH  THE  TESTING 

PICS  # TSES  # 

PITR  # 

Test  Suite  ID  


Figure  16.  Page  5 of  the  T&R  Service  Registrant  DI 


Profiles  Referenced 


This  entry  demonstrates  interoperation  according 

TO  THE  PROFILES  LISTED  BELOW.  ThE  TESTS  REQUIRED 
TO  DEMONSTRATE  INTERWORKING  MAY  BE  FOUND  IN  THE 

Test  Requirements  Specifications  corresponding  to 

THE  PROFILES  LISTED  BELOW. 

Profile  Referenced: 


j 

I 

I 


Figure  17.  Page  6 of  the  T&R  Service  Registrant  DI 
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I DERIVED  SYSTEMS  I 

1 1 

I The  information  listed  below  describes  a product/system  which  I 

I COMPANY  A HAS  IDENTIFIED  AS  A DERIVATIVE  OF  THE  TESTING  PERFORMED.  I 

I 1 

I Product  Specification  I 

I Hardware  Platform  1 

I I 

I Operating  System  i 

I I 

I Application  Profile  1 I 

I 2 I 

I 3 I 

I I 

I Transport  Profile  I 

I I 

I Relay  Profile  I 

I 1 

I Interchange  Profile  I 

+ ^ 

Figure  18.  Page  7 of  the  T&R  Service  Registrant  DI 


DETAILED  TES'  RESULTS 


Listed  below  are  the  test  reference  numbers  of  every  test  successfully  com- 
pleted BETWEEN  Company  A and  B.  Test  numbers  selected  for  testing  include 

ALL  THE  MANDATORY  TESTS  AND  THE  OPTIONAL  TESTS  SELECTED  BY  COMPANY  A AND  B 
WHICH  DEMONSTRATE  THE  FEATURES  SUPPORTED  BY  BOTH  PRODUCTS. 


Figure  19.  Page  8 of  the  T&R  Service  Registrant  DI 
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4.2.1  A Typical  T&R  Service  User  Scenario 

A T&R  service  user's  typical  scenario  might  proceed  as  follows. 
After  logging  into  the  system  and  selecting  the  appropriate  menu 
selections,  the  user  is  presented  with  the  blank  DI  electronic 
form.  The  user  pushes  the  "ENTER  QUERY"  key  and  then  proceeds  to 
fill  in  whatever  items  on  the  form  he/she  wants  used  as  query 
criteria.  If  the  interest  is  for  "all  entries  registered  by  IBM", 
the  user  would  enter  into  the  field  labeled  "Test  Party  A"  the 
letters  "IBM". 

Then  as  instructed  by  the  "help"  line  at  the  bottom  of  the  screen, 
the  user  presses  the  "EXECUTE  QUERY"  key.  The  pressing  of  the 
"EXECUTE  QUERY"  key  terminates  the  input  of  the  query  and  initiates 
the  retrieval  of  the  test  result  information  that  meets  the  entered 
criteria.  The  T&R  service  presents  to  the  user  the  first  page  of 
the  first  record  from  the  entries  it  found  satisfying  the  selection 
criteria.  The  user  uses  the  arrow  keys,  the  "NEXT  RECORD"  key,  and 
the  "PREVIOUS  RECORD"  key  to  cycle  through  the  entries  selected 
from  the  database  in  answer  to  the  query. 

In  the  above  scenario,  the  user  only  filled  in  one  field  value;  but 
any  combination  of  fields  could  have  contained  values.  Most  field 
values  entered  act  as  query  qualifiers.  The  T&R  service  restricts 
the  the  use  of  some  fields  as  query  qualifiers,  since  querying  on 
these  fields  in  not  meaningful.  If  a particular  combination  of 
fields  yields  no  records  or  entries  the  user  is  informed,  "No 
records  selected".  The  T&R  User's  Guide  lists  the  fields  most 
helpful  for  use  as  query  selection  criteria. 

Two  additional  scenarios  illustrate  the  construction  of  multiple 
field  queries.  In  one  scenario  the  user  is  interested  in  all  Touch 
Communications  and  NCR  products  which  have  interoperated.  Here  the 
user  again  presses  the  "ENTER  QUERY"  key.  The  user  then  enters  the 
letters  "Touch  Communications"  into  the  field  labeled  "TEST  PARTY 
A".  And  the  user  enters  the  letters  "NCR"  into  the  field  labeled 
"TEST  PARTY  B" . The  user  next  presses  the  "EXECUTE  QUERY"  key. 
The  database  then  notifies  the  user  of  the  records  which  satisfy 
the  query. 

When  a user  has  completed  all  query  requests  to  the  database, 
he/she  exits  the  DI  form  by  pressing  the  "EXIT/CANCEL"  key.  The 
user  is  then  returned  to  the  menu. 


4.2.2  A Typical  T&R  Service  Registrant  Scenario 

A T&R  service  registrant  may  perform  several  functions,  but  each 
function  results  in  either  a query  or  a store  operation.  In  the 
case  of  a query  operation,  the  above  user  scenario  applies.  The 
next  several  paragraphs  will  address  a typical  storing  scenario. 
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After  a T&R  registrant  has  logged  into  the  system  and  made  the 
appropriate  menu  selections  to  register  test  results,  he/she  is 
presented  with  the  T&R  registrant  blank  DI  form.  The  first  page 
of  this  form  requires  the  T&R  registrant  to  "log  in”.  This  logging 
function  is  necessary  to  determine  that  the  person  wishing  to 
register  test  results  is  indeed  a registrant  of  the  T&R. 

The  T&R  registrant  is  required  to  enter  a username/password.  The 
database  then  checks  to  make  sure  that  this  username/password  is 
in  the  Registrant  Information  table.  If  the  username/password  can 
not  be  found  in  the  Registrant  Information  table,  the  database 
informs  the  T&R  Registrant,  "This  username/password  is  not 
registered;  please  contact  the  Database  Administrator  (DBA)”.  If 
a T&R  registrant  receives  this  message,  he/she  is  restricted  from 
doing  anything  and  must  contact  the  T&R  service  DBA  to  be  given 
access . 

After  the  T&R  ^gistrant  has  successfully  "logged"  into  the  DI 
application,  h she  may  proceed  to  page  2 of  the  DI  form  by 
pressing  the  ^:XT  BLOCK”  key.  In  this  scenario,  the  T&R 
registrant  is  interested  in  registering  test  results.  The  T&R 
registrant  registers  the  results  by  first  pressing  the  "CREATE 
RECORD"  key.  The  T&R  registrant  then  enters  data  into  the 
appropriate  fields  of  the  DI  form.  Once  all  pages  of  the  DI  form 
have  been  filled  out,  the  T&R  registrant  presses  the  "COMMIT"  key. 
This  alerts  the  database  that  data  entry  is  complete  and  the 
database  then  inserts  this  row  or  record. 


4.3  The  T&R  Service  Terminal  Types  Supported 


The  VT100/VT220/VT330/VT'' 
Terminal  support  for  IBM 
provided  in  the  near  fut 


0 terminal  types  are  currently  supported, 
"/compatibles  and  3270  terminals  will  be 
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4.4  The  T&R  Service  Keypad  Layouts 
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Figure  20.  The  T&R  Service  Keypad  Layout  for  the  VTIOO 
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Figure  21. 


The  TficR  Service  Keypad  Layout  for  the  VT220 
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5.  The  T&R  Service  Message  Handling  System  Access  Method 

This  access  method  is  implemented  by  extending  the  capabilities  of 
the  Network  Information  Center  (NIC) . T&R  registrants  can  indicate 
a request  to  register,  or  update  test  results  in  the  Subject  field 
of  the  message  content.  The  body  part  of  the  message  contains  the 
test  results  to  be  registered  or  updated. 

T&R  registrants  and  users  can  query  test  results  by  requesting  one 
of  the  query  messages  maintained  by  the  T&R  service.  Each  query 
message  contains  the  actual  SQL  required  to  perform  a specific 
query.  The  user  or  registrant,  upon  receiving  the  query  message, 
fills  in  the  blanks  and  sends  it  back  to  the  T&R  sercice.  The 
query  is  submitted  to  the  database,  the  results  of  the  query  are 
written  to  a file,  which  is  then  sent  back  to  the  user  or 
registrant . 

All  retrieval  capabilities  using  the  asynchronous  access  method 
are  available  in  the  MHS  access  method.  Other  requests  such  as 
change  T&R  registrant  password,  retrieve  directory  information,  and 
access  EXAMPLE  database  will  also  be  indicated  in  the  Subject 
field.  The  T&R  service  provides  a template  file  to  T&R  service 
registrants  who  wish  to  use  the  MHS  access  method  to  register  or 
update  test  results. 


5.1  The  T&R  Service  MHS  Access  Method  Error  Messages 

There  are  two  kinds  of  errors  that  could  result  using  the  T&R 
service  MHS  access  method  of  operation.  The  first,  and  probably 
most  frequent  is  a typing  error. 

If  there  is  an  error  in  the  request  type,  the  parser  will  not  be 
able  to  process  the  request.  The  automated  T&R  service  function 
will  build  an  X.400  message  containing  the  error  field  and  an 
explanation  about  the  nature  of  the  error,  and  return  it  back  to 
the  message  originator. 

The  second  type  occurs  if  the  message  originator  address  on  the 
message  envelope  is  incorrect.  When  this  results,  the  T&R  service 
will  not  be  able  to  send  a message  back  to  the  message  originator. 
In  this  case,  the  automated  T&R  service  process  will  save  the 
contents  of  this  message  in  a file  for  later  investigation.  If  the 
message  originator  has  not  received  a response  within  a reasonable 
time,  he/she  should  call  the  appropriate  T&R  service  contact  person 
at  the  NIST.  This  type  of  error  should  rarely  occur. 


6.  The  T&R  Service  Packet  Assembler/Disassembler  (PAD)  Access 
Method 

The  T&R  service  offers  PAD  access  via  OSINET  for  users  who  do  not 
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choose  to  register  via  asynchonous  terminal  or  MHS.  Access  as  this 
level  is  very  similar  to  asynchonous  terminal  access.  The  major 
difference  is  the  initial  connection  details.  After  the  connection 
to  the  T&R  service  is  made,  everything,  including  login  prompts  and 
forms  presented,  is  identical  to  asynchonous  terminal  access. 

All  users  wanting  to  communicate  with  the  T&R  service  using  the  PAD 
access  method  must  have  a computer  with  PAD  support  and  a 
connection  to  OSINET  or  have  PAD  access  via  local 
telecommunications  company  support.  The  latter  method  requires  a 
user  to  dial  into  the  local  service  via  a modem  and  then  connect 
to  the  T&R  service. 


7.  The  T&R  Service  Protective  Mechanisms 

The  T&R  service  has  protective  mechanisms  incorporated  at  the 
system  level,  the  database  level  and  the  application  level.  The 
following  sections  describe  in  detail  the  overall  protection 
provided  by  the  T&R  service. 


7.1  The  DEC  VMS  Captive  Account  Feature 

The  DEC  VMS  captive  account  feature  provides  the  capability  of 
restricting  user  interrupts  and  allows  the  user  to  be  kept  under 
the  control  of  the  login  command  procedure.  The  user  is  not 
permitted  to  enter  the  system  command  level.  Any  attempts  will 
result  in  termination  from  the  account. 


7.2  The  Protective  Features  of  Application  Menus 

The  user  is  not  allowed  to  access  the  system  level  from  the  menus. 
If  any  attempt  is  made,  it  will  result  in  termination  from  the 
account. 

The  menu  options  only  permit  the  T&R  registrants  providing  a valid 
username  and  password  to  register  or  update  test  results.  The 
users  are  only  given  the  permission  to  VIEW  the  database  tables 
thru  the  menu  options. 


7.3  The  Protective  Features  of  Application  Forms 

The  use  of  application  forms  insures  that  the  T&R  service  is 
protected.  An  application  form  limits  access  to  the  database 
through  a variety  of  methods.  The  following  paragraphs  give  the 
details  of  the  protective  features  built  into  the  T&R  service  via 
the  DI  application  forms. 

Users  and  T&R  registrants  do  not  see  the  same  database  form.  Users 
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are  presented  with  a form  which  only  allows  query  operations. 
Users  are  restricted  from  making  changes  to  the  database.  T&R 
registrants  may  perform  several  specialized  functions  in  addition 
to  the  normal  user's  functions.  T&R  registrants  may  register 
entries,  modify  entries  with  "DRAFT"  status,  and  change  the  status 
and  update  the  derived  systems  and  marketing  contact  information 
in  "CURRENT"  entries. 

Regardless  of  the  action  being  performed,  T&R  registrants  receive 
a special  database  form  which  requires  them  to  "log  in"  using  a 
username/password  which  is  stored  in  a password  table  in  the 
database.  If  the  username/password  entered  is  not  in  the  password 
table,  access  to  the  database  is  denied.  Only  persons  with 
Database  Adminstrator  (DBA)  privilege  can  view  the  password  table. 

Note  that  T&R  registrants  only  receive  this  special  form  if  they 
choose  menu  options  which  identify  them  as  a T&R  registrant.  If 
a T&R  registrant  is  only  interested  in  querying  the  database, 
he/she  may  access  the  T&R  as  a user.  A T&R  registrant  entering 
the  system  as  a user  never  sees  the  special  form  and  the  activities 
are  limited  to  those  of  a user. 

Once  the  T&R  registrant  is  logged  in  via  the  special  form,  he/she 
is  able  to  perform  any  of  the  specialized  functions  reserved  for 
T&R  registrants.  There  is  further  protection  provided  here  as 
well.  T&R  registrants,  who  are  registering  new  entries,  changing 
"DRAFT"  entries  or  changing  the  status  of  an  entry  from  "DRAFT"  to 
"CURRENT",  are  accessing  the  WORKING  database.  If  the  T&R 
registrant  is  changing  the  status  of  an  entry  from  "CURRENT"  to 
"OBSOLETE"  or  "INVALID",  then  he/she  is  accessing  the  PERMANENT 
database. 

At  the  form  level  there  is  even  further  protection.  This  level 
protects  the  integrity  of  the  data  in  the  database.  At  this  level 
each  data  field  on  the  form  is  checked  to  make  sure  that  the 
response  is  on  a list  of  valid  responses,  that  the  data  is  within 
an  appropriate  range,  and  that  all  fields  which  are  mandatory  have 
been  entered.  And  it  is  at  this  level  that  the  database  checks  for 
duplicate  entries. 


29 


8.  The  T&R  Service  Project  Schedule  & DelivereUsles 

Table  7 shows  the  list  of  deliverables  for  the  T&R  service  project 
and  the  approximate  date  of  delivery  for  each. 


T&R  SERVICE  PROJECT  DELIVERABLES 

- - - - - . . L 

DELIVERY  DATE 

DRAFT  Functional  Specification 

November  1989 

Final  DRAFT  Functional  Spec. 

May  1990 

Completed  Da  base  - Async  Access 
DRAFT  User  3uide 

June,  1990 

Final  DRAFT  ser's  Guide 

Nov.,  1990 

X.400  Access  to  T&R  service 

Sept.  1991 

NISTIR  Versions  of  T&R  User's 

Guide  & T&R  Functional  Spec. 

July  1991 

Transition  of  T&R  Service  to  COS  | 

August  - Sept.  1991 

TadDle  7.  The  T&R  Service  Project  Schedule  & DeliveradDles 


9.  ^ T&R  Service  Project  Contacts 


Tabic  3 below  lists  the  NIST  contacts  associated  with  the  T&R 
servi^5.  Each  person's  functional  role  and  telephone  number  are 
provided  with  their  name. 


FUNCTION 


NAME 


TELEPHONE 


NIST  T&R  Project 
Approval 

NIST  T&R  Project  Mgr. 
NIST  T&R 

Implementation  Team: 
COS  T&R  Project  Leader 


Kevin  Mills 

Jerry  Mulvenna 

Alper  Kerman 
Carol  Edgar 

Kathy  uen 


301-975-3618 

301-975-3631 

301-975-3387 

301-975-3613 

703-883-2700 


TaUsle  8.  The  T&R  Service  P^  ject  Contacts 
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